The present invention relates to a method of providing mobile communication by interconnecting a network conforming to a protocol to a network conforming to the protocol or another protocol.
In recent years, there has been an animated discussion about introduction of an internet protocol (IP) to a mobile communication network. The internet engineering task force (IETF) is making efforts to standardize mobile IPv6. A network of the mobile IPv6 includes a mobile node (MN), a home agent (HA), and a correspondent node (CN).
A unique IP address (home address) is assigned to each mobile node, the IP address being kept unchanged regardless of movement of the mobile node. A link having a prefix equal to a prefix of the home address is called a home link. When the mobile node moves to or visits a link other than the home link, the mobile node obtains an IP address in the visited link. This address is called a care-of address (C/O address).
The home agent maintains a binding cache, i.e., a pair of a home address of a mobile node and a C/O address thereof.
When a mobile node detects a movement, the mobile node sends a control signal (binding update) to the home agent to request update of the binding cache. Having received the control signal (binding update), the home agent multicasts a message (gratuitous neighbor advertisement) to capture or to acquire a packet addressed to a mobile node existing on other than the home link. The home agent serves as a proxy of the mobile node.
The correspondent node (CN) is a node to communicate with the mobile node. According to the mobile IPv6 specifications, since the mobile node sends a mobile IPv6 message to the correspondent node, the correspondent node must also conform to the mobile IPv6.
Description will now be given of a procedure for the correspondent node to transmit a packet to the mobile node.
The correspondent node sends a packet addressed to the mobile node to the home address. The home agent intercepts the packet addressed to the home address. The home agent retrieves the binding cache according to the home address of the mobile node and obtains the C/O address of the mobile node. The home agent adds to the received packet a header to send the packet to the C/O address (encapsulation of the packet). The home agent then transmits the packet to the mobile node.
Having received the packet, the mobile node removes the header beforehand added to the packet (decapsulation of the packet) to restore the original IP packet.
On receiving the packet thus encapsulated, the mobile node retrieves a binding update list of the mobile node using the IP address of the correspondent node. The binding update list includes information of binding update message destinations.
When the binding update list does not include an entry for the correspondent node, the mobile node sends a control signal (Binding Update) to the correspondent node to notify the C/O address of the mobile node.
Having received the binding update message from the mobile node, the correspondent node registers a pair of the home address and the C/O address of the mobile node to the binding cache of the corresponding node. Thereafter, the correspondent node directly sends the packet to the C/O address of the mobile node for route optimization. In the IP header of the packet, the C/O address of the mobile node and the home address thereof are set to a source address field and an IPv6 routing header field, respectively.
On the other hand, with rapid spread of IP networks, the technique to interconnect areas or domains of mutually different address systems to each other becomes more important.
For example, a method (IETF RFC1631) using a network address translator (NAT) is known as a technique to interconnect a network conforming to a private address to a network conforming to a public address.
The network address translator conducts translation between a private IPv4 address and a public IPv4 address. The basic network address translator changes the source or destination address when a datagram passes the translator (NAT) between two areas connected to each other by an NAT router. When an address space of the private network collides with an address space of the public network, a twice NAT technique is often employed to solve the address collision. The twice NAT technique changes the source and destination addresses when a datagram passes the twice network address translator (NAT) between two areas connected to each other by a twice NAT router.
To solve the address collision, the twice NAT operates as follows. To initiate communication with Host-X in the public area, Host-A in the private area sends a query packet for a domain name system (DNS) address of Host-X. A domain name service-application level gateway (DNS-ALG) acquires the query packet, and translates an address for Host-x to an address (Host-X PRIME) routable in the private area, and then returns the packet to Host-A. When the DNS address resolution is finished, Host-A starts communication with Host-X PRIME. At a point of time when the packet passes the twice NAT, the source address is translated into an address that the NAT has and the destination address is translated into Host-X. Similar translation is conducted also for a response packet from Host-X. IETF RFC2694 describes operation of the DNS-ALG in detail.
This example is a technique used when a network to which a first terminal belongs and a network to which a second terminal communicating with the first terminal belongs conform to the same communication protocol. When the communication protocol differs between the networks, for example, when a network (IPv4 network) conforms to IPv4 and a network (IPv6 network) conforms to internet protocol version 6 (IPv6), the translation to interconnect the networks to each other is conducted using the known methods such as NAT-PT (IETF RFC2766), and SOCKS64 (IETF RFC3089).
In these methods, the format of the IP packet is translated between IPv4 and IPv6. For example, the address translation is conducted between IPv4 and IPv6. A system to conduct the translation will be referred to as a translator hereinbelow. For the translation, it is required to beforehand create a correspondence between IPv4 addresses and IPv6 addresses. The correspondence is kept stored in the translator. When the correspondence is dynamically created each time a communication takes place, name resolution of a domain name system (DNS) is used in an initial step of the creation.
The domain name system is a system to translate a name (character string; fully qualified domain name (FQDN)) easily understood by a human such as a uniform resource locator (URL) of the web into an IP address. An operation to translate a name into an IP address will be referred to as name resolution hereinbelow. Today, almost all applications on the internet acquire an IP address of its communicating party or partner using the domain name system.
To start communication, the network address translator and the protocol translator continuously monitor DNS messages communicated before starting the communication, using the fact described above. The translator uses a query message for name resolution as a trigger to create translation information (such as a correspondence of IP addresses). Specifically, when an IPv6 terminal conducts name resolution for a name and a response thereto is an IP address of IPv4, the IPv4 terminal translates the IPv4 address into an IPv6 address and sends the IPv6 address to the IPv6 terminal. The IPv4 terminal establishes a correspondence between the IPv4 address before translation and the IPv6 address after translation. That is, the gateway (DNS-ALG) acquires the response message of name resolution to dynamically create translation information on the basis of the information items before and after translation.
A technique to transmit voice and sound via IP networks has been enthusiastically discussed today. Voice over internet protocol (VoIP) is a technique to transmit audio information via IP networks. The protocol (VoIP) first sets a temporary speech channel path (session) between two communication units or devices. Audio data configured in an IP packet is transferred through the communication path or route thus prepared. A session control protocol is required to control operation to establish a session between the communication units, to keep the session, and to disconnect the session.
The internet engineering task force (IETF) has stipulated specifications of a session initiation protocol (SIP; IETF RFC2543) to establish and to terminate a session for IP multimedia communication. The protocol (SIP) attracts attention as a VoIP session control protocol because of its high expandability of functions.
The session initiation protocol is an application protocol using a transport mechanism such as a transmission control protocol (TCP) and a user datagram protocol (UDP). The session initiation protocol is a text-based protocol and includes a header to transport a request or a response and a message body in which the contents of the session are described. For example, a session description protocol (SDP; IETF RFC2327) is used to describe the SIP session.
The session initial protocol uses architecture of a client-server model. The source client sends a SIP request to a proxy (a SIP server) of the destination client. The SIP server conducts address resolution of the destination of communication using the domain name system (DNS) or the like to establish a session between the terminals.
The SIP server is in a proxy mode or a redirect mode according to its function. The proxy mode is a method in which a proxy server mediates a session establishing request between a source client and a destination client. The redirect mode is a method in which the source client directly connects with the destination client using information of the destination obtained from a SIP redirect server.
Description will next be given of a SIP connection procedure using a SIP server in the proxy mode. When a terminal x on an IP network initiates audio communication with a terminal y using the session initiation protocol, the terminal x sends a call setting request (INVITE) to the SIP server. The SIP server determines location information of the terminal y and sends a call setting request thereto. The terminal y sends a response indicating reception of the call. The response is sent to the terminal x via the SIP server through which the call setting request has passed. The terminal x sends an ACK request to the terminal y to confirm reception of the response. The ACK request is transferred by the SIP server or is directly sent to the terminal y. As a result, the terminal x can communicate with the terminal y. Ordinarily, a call setting request and a response thereto include information (session description) to transfer user information (an audio packet) between the terminals x and y. The session description protocol or the like is used to prepare the session description. The terminal x (y) sends the user information to a destination specified by the terminal y (x).
The session initiation protocol identifies the communicating party using a SIP uniform resource identifier (SIP URI). A SIP client resisters location information to a registrar server. For example, an IP address is set as the location information. The registrar server sends the location information to a location server. The location server keeps a correspondence between SIP URI and the location information. The registrar server and the location server may be installed in the SIP server.
According to SIP and SDP specifications, information items of a terminal and a SIP server can be specified by IP addresses.
International telecommunication uniorn-telecommunication sector (ITU-T) has standardizes the ITU-T recommendation H.323 stipulating an encoding method and a call control method to handle audio and video information on a network, for example, the internet and a local area network (LAN) on which a bandwidth is not guaranteed. The recommendation H.323 is prepared for packet-based multimedia communication systems and are applicable to the protocol (VoIP). An H.323 system mainly includes a terminal, a gateway, and a gatekeeper. The gatekeeper has an address translation function and a bandwidth management function for a terminal and a gateway to access a local area network. Messages and protocols for the call control method and a data transfer method are standardized by the ITU-T recommendations H.225 and H.245.
The recommendation H.323 identifies a terminal by an alias address. The gatekeeper manages information of correspondence between alias addresses and transport addresses. For example, an IP address is set to the transport address.
With spread of the VoIP service, the internet engineering task force and ITU-T are discussing assignment of a telephone number (E.164 number or the like) to a VoIP terminal. An ENUM domain name system (DNS) establishes a correspondence between a telephone number and a uniform resource identifier (URI; SIP URI, H.323 alias address, etc.) The system (ENUM DNS) is based on the DNS architecture and protocol and is stipulated by RFC2916. A node to issue a query to the ENUM DNS translates a telephone number into an FQDN format and sends the query to the ENUM DNS. The ENUM DNS translates information of the FQDN into a uniform resource identifier beforehand registered on the destination side.